home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Cream of the Crop 26
/
Cream of the Crop 26.iso
/
bbs
/
mxu_v152.zip
/
UP_DOOR.DOC
< prev
next >
Wrap
Text File
|
1997-07-26
|
52KB
|
1,008 lines
╔═══════════════════════════════════════════════════════════════════════════╗
║ FIRST THINGS FIRST - READ THE FILE WARNING.TXT BEFORE PROCEEDING! ║
╚═══════════════════════════════════════════════════════════════════════════╝
┌╦══╦┐ ┌╦══╦┐ ┌╦═══╦┐
│╠══╩╗┐│╠══╩╗┐└╩═══╦┐
└╩═══╩┘└╩═══╩┘└╩═══╩┘
┌╦ ╦┐┌═╤╦╤═┐┌═╤╦╤═┐┌╔ ┌═╤╦╤═┐┌═╤╦╤═┐┌╔═══╦┐┌╔═══╦┐┌════╦┐
│║ ║│ │║│ │║│ │║ │║│ │║│ │╬══ │╬══ ┌─╔═╝─┘
└╩═══╩┘ ╧╩╧ └═╧╩╧═┘└╩═══╩┘└═╧╩╧═┘ ╧╩╧ └╩═══╩┘└╩═══╩┘└╚════┘
┌╦═══╦┐┌╦═══╦┐┌╔═══╦┐┌═╤╦╤═┐┌╦ ╦┐┌╦═══╦┐┌╦═══╦┐┌╔═══╦┐
└╩═══╦┐│║ ║││╬══ │║│ │║ ╦ ║│├╬═══╬┤│╠══╦╩┘│╬══
└╩═══╩┘└╩═══╩┘└╩ ╧╩╧ └╩═╩═╩┘└╩ ╩┘└╩ ╚═┘└╩═══╩┘ <tm>
A Subsidary Of LA-Soft
───────────────────────────────────────────────────────────────────────────────
▀▀▀ ▀▀▀ ▀▀▀▀▀ ▀▀ ▀▀
▀▀▀▀ ▀▀▀▀ ▀▀ ▀▀ ▀▀ ▀▀
▀▀ ▀▀▀ ▀▀ ▀▀▀▀▀▀▀ ▀▀▀ ╔══ ╦═╗ ╔═╗ ╦═╗ ╦ ╦ ╦ ╔═╗ ╔═╗
▀▀ ▀ ▀▀ ▀▀ ▀▀ ▀▀ ▀▀ ║ ╦ ╠╦╝ ╠═╣ ╠═╝ ╠═╣ ║ ║ ╚═╗
▀▀ ▀▀ ▀▀ ▀▀ ▀▀ ▀▀ ╚═╝ ╩╚═ ╩ ╩ ╩ ╩ ╩ ╩ ╚═╝ ╚═╝
───────────────────────────────────────────────────────────────────────────────
The Universal Multimedia Interface For BBS Software
Copyright 1995-Current * Larry L. Athey * BBS Utiliteez Software
───────────────────────────────────────────────────────────────────────────────
Information Regarding MAX Graphics:
───────────────────────────────────
Notice is hereby given that the MAXscript/MAXcontrol/MAXcolor language,
and MAXterm are products of BBS Utiliteez Software and are protected by
US copyrights listed with the US Library Of Congress (1996)....
No changes, additions, subtractions, or other modifications shall be made
to MAXscript/MAXcontrol/MAXcolor language or the MAX Graphics development
kit without express written permission from Larry L. Athey, BBS Utiliteez
Software, Alliance, Nebraska, USA....
The MAXscript/MAXcontrol/MAXcolor language may be used in any BBS or Door
software 100% royalty free. You are also allowed to implement full local
graphics viewing in any BBS or Door software 100% royalty free. However,
any program that uses the MAXscript/MAXcontrol/MAXcolor language *MUST*
bear the MAX Graphics/BBS Utiliteez Software copyright notice....
Example: MAX Graphics and the MAXscript/MAXcontrol/MAXcolor language is
(C) 1995-Current * Larry L. Athey * BBS Utiliteez Software
───────────────────────────────────────────────────────────────────────────────
The Contributors:
─────────────────
This is a list of people who contributed to the cause of beta testing the
MAX Graphics related programs and the TDK door development kit. Although
there were more people who applied to be beta testers, most of these beta
sites never posted anything in the support echo, so I don't consider them
to have made any contribution to the cause. But, these people stood by me
and my efforts without a single sour word, and never threw in the towel..
Many people apply to be a beta tester for new programs and never think of
the qwerks involved in testing untested software. So they quickly give up
and avoid beta testing like the plague. Beta testing requires a person to
do nearly as much work (if not actually more) as the programmer themself.
Programs can't evolve without testers actually running the program and at
least trying to make it work even with the bugs in it. True beta testers
don't seem to know the meaning of the phrase "I give up", and that's what
makes being a program author worth while. I couldn't give a damn if I get
one more program registration in my life, so long as there are dedicated
common sense thinking people like this standing by you, it's worth while!
Let's here it for the people that refused to say "I give up"!
Name: BBS: Phone:
───────────────────────────────────────────────────────────────────────────
Brad Larned (1:205/400) The Fresno Online BBS 209-276-3657
Sean Price (1:205/46) Sanctuary From The Law BBS 619-377-3611
Chris Martin (1:219/308) The Mars Station BBS 760-254-3012
Bob Wingender (1:284/11) The Oak Tree BBS 417-581-0868
Chet Rhodes (1:151/124) Hawkmoon's Realm 919-556-8363
Larry Thrasher (1:3612/650) The Night Thrasher BBS 904-937-9144
Thomas Wells (1:3621/1) Renegade's Hideout 615-326-5597
Timothy Barney (1:2622/3) The Gravel Pit 814-942-1552
Cliff Williams (1:112/124) The City Of Thought 904-645-8850
Jon Parise (1:2606/421) Infinite Twilight 908-637-8243
Arthur Stark (1:395/670) Top's Diamond Mine 254-542-8783
Ronald Schlegel (1:110/1065) Dynasty BBS 937-258-1030
David Raasch (1:280/285) Let It Shine Online! 816-461-2290
───────────────────────────────────────────────────────────────────────────
NOTE: These names appear in no particular order, they are only listed here
as the names appear in my MAX Graphics area message base....
───────────────────────────────────────────────────────────────────────────────
This program was written using:
▀▀▀▀▀▀▀▀ ▀▀▀▀▀▀ ▀▀ ▀▀
▀▀ ▀▀ ▀▀ ▀▀ ▀▀
▀▀ ▀▀ ▀▀▀ ▀▀▀▀▀ The DoorKit!
▀▀ ▀▀ ▀▀ ▀▀ ▀▀
▀▀ ▀▀▀▀▀▀ ▀▀ ▀▀
The BBS Door Development Kit By The People - For The People!
───────────────────────────────────────────────────────────────────────────────
The ANSI/ASCII/RIP/MAX DoorKit v1.35
No Copyright Notices Expressed Or Implied
Compiled By Larry L. Athey From Numerous Sources
───────────────────────────────────────────────────────────────────────────────
DISCLAIMER:
-----------
This program's author has taken every precaution to insure that no harm or
damage will occur on computer systems operating this package. Nevertheless,
the author shall NOT be held liable for whatever may happen on your computer
system or to any computer systems which connects to your own as a result of
operating this package. The user assumes full responsibility for the correct
operation of this software package, whether harm or damage results from any
software error, hardware malfunction, or operator error. NO warranties are
offered, expressly stated or implied, including without any limitation or
restriction any warranties of operation for a particular purpose and / or
merchantability. If you do not agree with this, then absolutely do NOT use
this program! See the file WARNING.TXT for more information....
───────────────────────────────────────────────────────────────────────────────
LICENSE AGREEMENT:
------------------
The door program, support files, and documentation are copyrighted products
of BBS Utiliteez Software. The author reserves all rights to these products.
This is protected by the United States of America (USA) and International
Copyright Laws. In no way shall the components of the door software package
be reproduced or modified in any form or method without prior expressly
written permission from the author.
Tampering with or altering the contents or integrity of the door software
package is prohibited. No fee may be charged by any agency other than the
author beyond the cost of distributing unregistered copies without prior
expressly written permission from the author.
This door is distributed as freeware, but is not public domain software.
───────────────────────────────────────────────────────────────────────────────
GUARANTEE:
----------
Ha Ha Ha Ha....Guarantee? Okay, if this program breaks, I guarantee that you
get to keep both pieces....How's that? :)
───────────────────────────────────────────────────────────────────────────────
WHAT'S NEW:
-----------
Added more command line parameters which will actually allow MAXupdate
to run without a drop file at all.
Added the /X command line parameter which will force MAXupdate to send
a !|1K|*|#|#|# upon program exit which will force MAXterm to jump back
to text (ANSI Emulation) mode.
Now allows you to specify a singular RESOURCE.LST on the command line,
thus allowing you to use MAXupdate more effectively with just one door
at a time.
Lower memory requirements and smaller executables. This is due to the
fact that all local SVGA code was removed from the TDK door kit.
Neater and more organized activity logging.
MAXLIST.EXE no longer allows you to put any ICON_LIB.* icon libraries
in your resource lists. No point in sending the caller 400K of icons
that they already have by default anyway.
All the benefits of the new features, bug fixes, and changes to TDK....
───────────────────────────────────────────────────────────────────────────────
╔═══════════════════════════════════════════════════════════════════════╗
║ THE MAX GOLDEN RULE ║
╚═══════════════════════════════════════════════════════════════════════╝
The golden rule of MAX Graphics is one that for some reason just can't be
stressed enough...That ever so important rule is that you ABSOLUTELY MUST
be able to call into your BBS to test and debug things as you add/change
them. Too many people try to add MAX Graphics to their BBS or Doors, then
get frustrated because their users keep saying "This doesn't work!", when
the reason it doesn't work is because the SysOp just didn't test things..
Yes, granted that MAX Graphics will in theory drop into your BBS or Doors
and replace the existing RIP interface, you have to keep in mind that you
are dealing with a completely different animal with MAX Graphics...In RIP
you usually have some amount of ANSI text displaying on the screen at all
times unless you send a RIP command to disable/hide the text window...MAX
Graphics is the exact opposite of this. MAX Graphics is primarily an SVGA
graphical user interface with zero ANSI text displaying unless you force
MAXterm to display it either with a Text_View_Port command, or by telling
MAXterm to flip all the way back to ANSI emulation mode by sending !|1K|*
to the comport with a screen file or a menu command...This is the biggest
problem that most SysOps have...They tend to overlook this rule no matter
how many times it is stressed in the MAX Graphics specifications...
This is the very reason that the golden rule of MAX Graphics is that you
be able to call into your BBS and test things before you EVER allow users
access to the MAX side of your BBS...If you neglect to follow this simple
rule and just drop a bunch of MAX screens into your BBS, and hope for the
best. I can guarantee you that "The Best" is _FAR_ from what you will end
up with...What you will most likely end up with is a lot of carrier drops
because a user is stuck staring at a blank SVGA backdrop image while your
BBS is trying to display an ANSI screen file. The user will assume either
the BBS or their terminal program has locked up and reboot their machine.
You will most likely end up with a few nasty comments from the user after
they call back with their good old reliable ANSI terminal program...
There you have it, an ever so basic rule that any SysOp should be able to
remember. If you don't have a second computer, just throw an old 2400 BPS
modem in your existing machine and install some kind of a multi-tasker. I
can guarantee that if you just take the time to test & debug things first
then MAX Graphics WILL work for you and your users...
───────────────────────────────────────────────────────────────────────────────
DESCRIPTION:
------------
This program is a Multi-BBS compatible door that allows you to update your
caller's MAXterm terminal program and their resource files while online.
This program can be run as a basic BBS door, or it can also be run between
your BBS and front end mailer. It is suggested that you run this program
in a PRELOG.BAT (or comparable batch file) in your BBS, or in between your
BBS and front end mailer.
Since you have implemented MAX Graphics in your BBS, you most likely don't
want people calling your system using RIPterm. So if you run this program
in "Front End Mode" and configure it accordingly, you can block out RIPterm
callers from your BBS all together. Before this program will drop carrier
on the RIPterm caller, it will give them the option to download MAXterm
before dropping them. You can also configure the program to exit normally
and not hang up on RIPterm callers.
This program also has pre-defined DOS errorlevels programmed into it that
it will exit with depending on the terminal emulation detected. This is a
handy feature if you are running the program in front of your BBS. This
will allow you to detect whether the remote is using RIPterm or MAXterm,
and then allow you to do pre-logon screen file copying.
No external protocol driver units are needed for this program. MAXupdate
has built in Zmodem, Ymodem, Ymodem-G, Xmodem and Xmodem-1K protocols.
NOTE: This door requires you to have the latest version of the MAXterm
archive and its SETUP.EXE & MXT.RES stored someplace on your hard
drive in order to update the remote's terminal program.
───────────────────────────────────────────────────────────────────────────────
WHAT EXACTLY ARE "RESOURCES":
-----------------------------
When the term "Resources" is used in MAX Graphics, this means font files,
sound files, image files, icon library files, MAXecutables, mouse cursors,
and remote stored screen files. The MAX screen files used by your BBS are
NOT what is referred to as a "Resource". Resources are basically any file
that a MAX screen file uses that your BBS isn't capable of sending on the
fly....
If you use any sound files in a screen file, the sound file must already
exist on the remote system before they will hear it. So you must get the
file from your system to their system BEFORE the BBS sends the screen to
them. The same rule applies to any other resource file, it must already
exist on the user's system before the user can play/display/process it.
That's what this program is for, this program sends the resources to a
user before they log on to your BBS and basically maintains their .PKG
file for your BBS and to make sure your users always have the most up
to date version of MAXterm.
───────────────────────────────────────────────────────────────────────────────
ONE QUICK NOTE BEFORE WE START:
-------------------------------
I'm going to apologize ahead of time in case any part of this documentation
seems kind of vague. I'm a programmer, not a teacher, so all I can do is my
best. Plus, it appears that there is a world wide campaign to abolish the
reading of any and all documentation, so I really don't spend a whole hell
of a lot of time writing any documentation any more. If for some reason you
can't understand what a certain feature does by reading this document, all
I can suggest is that you tinker around with that feature for a while until
you understand what it's actually doing. Hands on experience is always the
best teacher and most effective way of learning something new....
───────────────────────────────────────────────────────────────────────────────
REQUIREMENTS:
-------------
At this point in time the only requirement is that you have a computer. :)
You may or may not have to make modifications to other BBS configuration
files or your computer start up files. Chances are that you won't....
───────────────────────────────────────────────────────────────────────────────
SPECIAL CONSIDERATIONS:
-----------------------
Below is a list of special considerations to keep in mind before you install
this program. By following these considerations, you will save yourself and
your users a lot of headaches in the long run....
The main thing to remember about MAXupdate is that it is "Timing Dependent",
and if there is anything in your system interfering with the program timing,
it's not going to work correctly....
1. Disk compression is the worst thing you can do to your computer, this will
easily cost you 70% of your computer's overall performance. Yes I know, it
appears to provide you with twice the disk space. But the thing that most
people don't know is that you can't compress a file twice. If you store a
100K ZIP file on a compressed drive, you'll see that you actually lose 250
to 300K of disk space. The same thing happens when you use programs where
the executables are compressed (such as this program). The only place that
disk compression works is with uncompressed files.
Disk compression also slows down your computer and chews up conventional
memory in a nasty way. Every time your computer accesses a compressed file
it has to decompress it into memory or to the host drive. If any changes
are made to the file, it has to be compressed again before it is saved. So
you might as well look at disk compression just like throwing a TSR into
your system that tells your computer it has to run PKZIP and PKUNZIP every
time it accesses a file.
This constant decompress/read/compress/save routine interferes with this
program severely because it is timing dependent. Since MAX Graphics uses
non-error-correcting text based transfer routines, disk compression will
cause this program to perform erratically, or prevent it from working at
all depending on the system. If you use any disk compression, then it is
in your better interests not to bother installing this program until you
have removed the disk compression. MAXupdate is only tuned to work with
as slow as a 2400 baud modem, and when your computer is contantly doing
that decompress/read/compress/save routine, the timing routines in this
program simply will not work correctly.
2. When running this program under a multi-tasker, you must be sure that the
DOS session has enough priority that another program running in another
session isn't interfering with the timing routines. If you have a program
running in another session that is hogging the CPU, it _could_ cause the
results from a MAXterm query to get botched. If this happens, your users
will usually start complaining because MAXupdate is always forcing them
to download the same resources on every call. This will usually weed out
your long distance callers if your system is doing this. :)
3. Be sure that you know your modem/fossil driver input and output buffer
sizes in advance. For error free communications, you must configure the
control files (ie: NODE###.CTL) correctly, and this is the main thing a
lot of people overlook or set incorrectly. Setting these incorrectly is
like trying to join two different sizes of pipe, you can't do it without
a causing a leak. So be sure these settings are correct!!!
4. This program requires you to be able to pass the caller's actual baud
rate on the command line. The port locked speed is obtained from your
control files. The /S parameter is used to tell the program what speed
the caller is actually connected at so the protocols can work correctly.
Passing the locked port speed on the command line will guarantee you a
bunch of errors in resource updates.
5. Any time you update this program, or update your system resources, you
absolutely MUST run the MAXLIST.EXE utility to create new RESOURCE.LST
files. If you neglect to do this, your updates are never going to work
or your users will be complaining about MAXupdate forcing them to down-
load the same resources all the time.
6. If you do happen to encounter callers telling you that MAXupdate forces
them to contantly download the same resources over and over, you will
need to see what their terminal is sending back for a resource list and
compare it against your resource list(s). When MAXupdate queries MAXterm
for a resource list, it will create a file in the program home directory
named RES.### where the ### is the current node number. While the caller
is online, you will need to either drop to DOS, or open up another DOS
session under your multi-tasker and copy this file to a safe place so it
can be viewed later. This is because MAXupdate cleans up after itself at
exit time and that file will be deleted. After the caller logs off, look
at this file in a text editor and compare the file names and their CRC32
values against your resources list(s). If the file is neatly formatted
(ie: {File Name} {one space} {CRC32 Value}) and the CRC32 values are not
correct, then you need to run MAXLIST.EXE again to create a RESOURCE.LST
with the correct values. If the file is improperly formatted, with just
partial file names or CRC32 values, then your control file settings are
incorrect, or there is a bug in your Fossil/DigiBoard driver program....
───────────────────────────────────────────────────────────────────────────────
INSTALLATION:
-------------
1. Create a directory for the door (example: "C:\DOORS\UP_DOOR").
2. Copy all the contents of this archive into that directory.
3. Run the door MAKECTL.EXE configuration program and edit the file
UP_DOOR.CFG to your preference. The UP_DOOR.CFG file is commented
to explain what each line of the configuation file is for. You will
also need to edit the DIR.LST file. See the section below on that
file to understand its function and how to edit it.
4. To insure proper multi-node use in a DOS based multi-tasking environment,
SHARE.EXE must be installed prior to the door, and prior to the OS.
5. In order to run the door program online, the following parameters may
be used. For a list of all available command line parameters, simply
execute the program with no parameters....
DropFile Specifiers:
--------------------
"/D={Node Work Path}\DOOR.SYS" - This tells the program to use the
DOOR.SYS drop file and the {Node Work Path} points to the proper
directory where the drop file is to be created or found.
"/R={Node Work Path}\DORINFO#.DEF" - This tells the program to use the
DORINFO#.DEF drop file and the {Node Work Path} points to the proper
directory where the drop file is to be created or found.
Optional Parameters:
--------------------
"/S##### (Where ##### is the user's actual baud rate) - This specifies
the online caller's actual baud rate. You use this parameter to force a
new baud rate if you are running the door with the DOOR.SYS drop file
and would like to force the door to use the actual baud rate rather than
the locked port speed. This is needed for the file transfer protocols to
work correctly.
"/N###" (Where ### is 1..?) - This specifies the current node number and
tells the door which NODE###.CTL file to use.
"/L" - This tells the door to load up in LOCAL mode.
"/O" - This tells the door to load up in ONLINE mode. This is useful if
you are running the door online without a drop file. Such is the case if
you wanted to run the door between your BBS and a front end mailer or a
waiting for caller program where no drop files are created in advance.
"/X" - This tells the door to send a !|1K|*|#|#|# at exit time to either
clear the remote screen in RIPterm or to flip MAXterm back to text mode.
"/U#####" (Where ##### is the user's actual BBS record number) - This is
used in the event the door needs to know the user's actual record number
when it is not contained in the drop file, or if no drop file is in use.
"/A#####" (Where ##### is the user's actual BBS access level) - This is
used in the event the door needs to know the user's actual access level
when it is not contained in the drop file, or if no drop file is in use.
"/T#####" (Where ##### is the user's remaining time in minutes) - This
is used in the event the door needs to know the user's actual remaining
online time when it is not contained in the drop file, or if no drop
file is in use.
"/E#####" (Where ##### is the number of minutes until your next event)
This is used in the event the door needs to know when the next event in
your BBS is to take place when it is not contained in the drop file, or
if no drop file is in use.
"/Z[FirstName_LastName]" - This is used in the event that you have to
force the user's name and alias in the door. If there is a first name
and last name, they must be separated by an underscore, not a space..
───────────────────────────────────────────────────────────────────────────────
THE UP_DOOR.CFG FILE:
---------------------
5
2.02
C:\FILES\MXT_B202.EXE
C:\MAXTERM\SETUP.EXE
C:\MAXTERM\MXT.RES
C:\MX\LOGS\
NODE{NODE}.LOG
YES
----------------------------------------------------------------------------
Definition of the UP_DOOR.EXE configuration file:
----------------------------------------------------------------------------
Line #1: How many seconds to wait for possible slowpoke remote machines.
This may be required if you have a number of people calling your
system with slowpoke 386/SX machines. This tells the door to sit
and wait for "X" amount of seconds for their machine to kill all
active windows before starting up the door.
Line #2: The version of MAXscript/MAXcontrol/MAXcolor your system supports.
The MAXTERM.DOC file in the MAXterm archive will say at the top of
it which version it supports.
Line #3: The full path and file name of your complete MAXterm archive.
Line #4: The full path and file name of your MAXterm setup program.
Line #5: The full path and file name of your main MAXterm installation
resource file. This file and the one defined in the above are
found inside of the actual MAXterm distribution archive. You
will need to extract these files from the archive and put them
in a directory where MAXupdate can find them.
Line #6: The full path to your BBS log files.
Line #7: The name of the log file to write to. The {NODE} variable will
be translated to the correct node number which will allow you
to run this door effectively with multi-node systems.
Line #8: Set this to YES or NO to tell the program whether or not to drop
carrier on RIPterm callers. If you are running this program in
front of your BBS and want to block out all RIPterm callers, then
set this to YES. Otherwise, set it to NO so this program doesn't
constantly hang up on RIPterm callers.
───────────────────────────────────────────────────────────────────────────────
THE CONTROL FILE EDITOR:
------------------------
┌─────────────────────────────────────────────────────────────────────┐
│ Editing Control File For Node #1 │
├─────────────────────────────────────────────────────────────────────┤
│ SysOp First Name:[Your First Name_____] │
│ SysOp Last Name:[Your Last Name______] │
│ Name Of This BBS:[Your BBS Name___________________________] │
│ SysOp Security:[500__] │
│ Serial Number:[__________] │
│ BBS Home Path:[C:\MX\______] │
│─────────────────────────────────────────────────────────────────────│
│ Using Fossil:[Y] Input Buffer Size:[4096] │
│ Locked Port Rate:[38400_] Output Buffer Size:[4096] │
│ Digi Over Ride:[N] Non-Standard Port:[N] Save ▄ │
│ Comm Data Bits:[8] Comport Number:[1_] ▀▀▀▀▀▀ │
│ Comm Parity:[N] Port IRQ Number:[4_] Quit ▄ │
│ Comm Stop Bits:[1] Port Hex Address:[03F8] ▀▀▀▀▀▀ │
└─────────────────────────────────────────────────────────────────────┘
SysOp First Name: Self Explanatory
SysOp Last Name: " "
Name Of This BBS: " "
SysOp Security: Set this to the same numeric value as the sysop
security level on your BBS.
Serial Number: Ignore this field....This is a freeware program,
so you will never be issued a serial number.
BBS Home Path: Enter the path to your BBS home directory here.
This has nothing to do with drop files, the path
to your drop files is passed on the command line.
this is used so this program can locate your BBS
system data files.
Using Fossil: Are you using a fossil driver? [Y/N]
Locked Port Rate: Enter the speed here in which your comport is
locked at.
Digi Over Ride: Do you want this program to use DigiBoard over
ride comm routines? [Y/N]
Comm Data Bits: Set to the same as your BBS's Data Bits setting.
Comm Parity: Set to the same as your BBS's Parity setting.
N=None, O=Odd, E=Even
Comm Stop Bits: Set to the same as your BBS's Stop Bits setting.
Input Buffer Size: Set this to the same as your BBS or fossil driver.
Output Buffer Size: Set this to the same as your BBS or fossil driver.
Non-Standard Port: Are you using a non-standard IRQ setting? [Y/N]
Comport Number: The comport number for this node (If Non-Standard).
Port IRQ Number: The IRQ number for this node (If Non-Standard).
Port Hex Address: This port's address in hex (If Non-Standard).
───────────────────────────────────────────────────────────────────────────────
SAMPLE BATCH FILES FOR RUNNING THE DOOR:
----------------------------------------
CD\DOORS\UP_DOOR
UP_DOOR.EXE /D=C:\BBS\NODE1\DOOR.SYS
CD\BBS
EXIT
or:
CD\DOORS\UP_DOOR
UP_DOOR.EXE /N2 /S14400 /R=C:\BBS\NODE2\DORINFO2.DEF
CD\BBS
EXIT
or:
CD\DOORS\UP_DOOR
UP_DOOR.EXE /X /D=C:\BBS\NODE1\DOOR.SYS
CD\BBS
EXIT
or:
CD\DOORS\UP_DOOR
UP_DOOR.EXE /D=C:\BBS\NODE1\DOOR.SYS /F=C:\DOORS\UP_DOOR\LORD\RESOURCE.LST
CD\BBS
EXIT
If you want to run MAXupdate in between your BBS and mailer or WFC program
and don't want to use the MAKEDROP.EXE program, MAXupdate allows you to use
a combination of command line parameters to allow this. Go back up in this
document and see the list of valid command line parameters....
Also, if you are running MAXupdate in front of your BBS and the BBS forces
the user to input a selection before any screen files are sent, you'll want
to use the /X command line parameter to force MAXterm back to text mode so
the user can see the prompt the BBS is presenting. Otherwise, the user will
be stuck staring at a blank SVGA backdrop with no idea what to do. One such
BBS package that would need this is TriBBS if you have it configured to use
more than one language....Use this feature as you see fit....
───────────────────────────────────────────────────────────────────────────────
OTHER SYSTEM FILES:
-------------------
MAXupdate makes use of three text files to handle its resource updating.
Two of these files are created manually with a text editor, whereas one
of them is created with the MAXLIST.EXE utility. Below is a list of the
files and a brief description of their purpose:
DIR.LST - This file is a list of directories on your system that hold
resource files to be sent before a caller logs on. If there
are any MAX compatible doors on your system that don't have
built in resource updating, you'll need to list the program
directory that hold that program's resources in here. This
is a plain text file with each directory on one line, each
directory may or may not contain a trailing backslash. This
file is to be located in the MAXupdate home directory.
RESOURCE.LST - For every directory listed in the DIR.LST file, there must
be a RESOURCE.LST file containing the file name and CRC32
value of each resource file on each line. This file should
be created by the MAXLIST.EXE utility in order to assure
each file is listed with the correct CRC32 value. This file
is to be located in the same directory as the resources to
be sent to the remote. This is a plain text file with the
file name, at least one space, and then the CRC32 value.
KILL.LST - This is an optional file that you manually create which is
used to delete old unneeded resources from the remote that
you no longer use on your BBS. This is just a courtesy on
your part. If you have sent resources to your users before
that you are no longer using, simply list the file name of
the resource in this file and it will be deleted from the
remote hard disk automatically. No CRC32 value is needed,
this file is also located in the MAXupdate home directory.
To create your RESOURCE.LST file(s), you simply execute MAXLIST.EXE with
the directory name on the command line. You will be prompted for a yes
or no response for every file located in that directory. This tells the
program whether or not you want to send this file to the remote caller
as a resource file. After the program exits, add the directory name to
the DIR.LST file using your text editor. That's all there is to it....
NOTE: Do *NOT* put any of the default ICON_LIB.* icon libraries in your
resource lists. These are default libraries that never need to be
sent to the user since MAXterm won't even begin to start without
them. There's no need to make a user download over 400K of icons
that they already have....Is there? :)
After all these files are configured, MAXupdate will do this when you run
it with a MAXterm caller online:
1. Read the NODE###.CTL and UP_DOOR.CFG files.
2. Query the remote for its system information and resource list.
3. Look for the KILL.LST file and delete any resource files from the
remote system (if they exist) that appear in this file.
4. Read the DIR.LST file and search for a RESOURCE.LST file located
in every directory listed in this file.
5. Check every file name and CRC32 value listed in the RESOURCE.LST
file against the list of resources on the remote system.
6. Send only the resources the remote doesn't have, or send the ones
the remote does have, but have a different CRC32 value.
7. Exit with the predefined MAX Graphics DOS errorlevel.
If you notice the definition for the "/F=" command line parameter in the
above, you can tell MAXupdate to just send the resources listed in one
RESOURCE.LST file. This is especially handy if you are running any doors
on your BBS where you have created MAX screen files for it and you need
to get the resources just for that door to the remote. Say that you have
the LORD&MAX package, you would extract the resources for that package
to a directory of your choice (ie C:\DOORS\UP_DOOR\LORD). Then you would
run the MAXLIST.EXE utility to create a RESOURCE.LST file. Then modify
the door start up batch file so that it runs MAXupdate first. You would
add something like this to your door start up batch file:
CD\DOORS\UP_DOOR
UP_DOOR.EXE /D=C:\BBS\NODE1\DOOR.SYS /F=C:\DOORS\UP_DOOR\LORD\RESOURCE.LST
Then whenever your BBS runs the door, MAXupdate will start up first, check
to see if the user needs resources, send them if needed, and then exit. If
you see below, MAXupdate also exits with specific error levels depending
on the terminal emulation detected. So you could actually support both MAX
and RIP in a door simply by trapping the errorlevel in a batch file, then
copy the needed screen files accordingly.
───────────────────────────────────────────────────────────────────────────────
PRE-DEFINED DOS ERRORLEVELS:
----------------------------
MAXupdate is programmed to exit with different DOS errorlevels depending
on the terminal emulation detected, and other detected conditions. Here
is a list or MAXupdate's pre-programmed DOS errorlevels:
0 - Normal Exit
1 - Comm Port Error
2 - Unable To Open Drop File
3 - Carrier Lost
4 - Time Limit Expired
5 - User Inactivity Time Out
6 - System File Missing
100 - TTY Graphics Detected / Normal Exit
101 - ANSI Graphics Detected / Normal Exit
102 - AVATAR Graphics Detected / Normal Exit
103 - RIP Graphics Detected / Normal Exit
104 - MAX Graphics Detected / Normal Exit
───────────────────────────────────────────────────────────────────────────────
RUNNING IN FRONT END MODE:
--------------------------
A utility (MAKEDROP.EXE) has been included in this archive to allow you to
run the door between a front end mailer and your BBS. What this utility
will do is create a DORINFO1.DEF drop file for the door to read which will
allow it to run online before a caller logs on to your BBS. The parameters
required for MAKEDROP.EXE are shown below:
MAKEDROP.EXE /N[Node #] /S[Baud Rate] /M[Minutes Left] /D=[DropFile Path]
Or:
MAKEDROP.EXE /N1 /S28800 /M30 /D=C:\BBS\NODE1\
After you have executed this utility and created the DORINFO1.DEF drop
file where you want it, you would execute the door program like this:
UP_DOOR.EXE /N1 /R=C:\BBS\NODE1\DORINFO1.DEF
───────────────────────────────────────────────────────────────────────────────
THE WFC.EXE PROGRAM:
--------------------
If you do not run a front end mailer, this program also contains a waiting
for caller unit. This program will answer calls to your BBS, start up the
UP_DOOR.EXE program, and then run the BBS.BAT file to start up your BBS...
You must create a WFC###.CFG file for every node your BBS runs. The ### is
the node number. See the WFC###.CFG file definition below:
THE WFC###.CFG FILE:
--------------------
AT&F
AT&C1&D2H0M1W2S95=2
ATA
500
2400
30
----------------------------------------------------------------------------
Definition of the WFC.EXE configuration file:
----------------------------------------------------------------------------
Line #1: Your modem's first initialization string. AT&F is a general reset
command which is compatible with all modems.
Line #2: Your modem's secondary (or main) initialization string.
Line #3: Your modem's answer string. ATA is a general answer string which is
compatible with all modems. Do not use ATS0=1 for answering!
Line #4: Your modem's command delay in milliseconds.
Line #5: The minimum allowable baud rate on your system.
Line #6: The maximum amount of minutes you want to allow users in UP_DOOR.
THE BBS.BAT FILE:
-----------------
@ECHO OFF
C:
CD\MX
MAXMENU.EXE /N%1 /B%2
This is just a generic example. The BBS.BAT file is called with the node
number as the first command line parameter, and the actual baud rate as
the second command line parameter.
───────────────────────────────────────────────────────────────────────────────
OTHER GENERAL INFORMATION:
--------------------------
Global System Variables Used By The Door:
-----------------------------------------
{TIME} = The Current Time
{DATE} = The Current Date
{NODE} = The Current Node Number
{BAUD} = The Current Baud Rate
{MINS} = Time Left Online In Minutes
{PORT} = The Current Comm Port In Use
{SEC} = The User's Security Level
{BBS} = Your BBS Name
{USER} = User's Full Name
{SYSOP} = SysOp's Full Name
{UFIRST} = User's First Name
{ULAST} = User's Last Name
{SFIRST} = SysOp's First Name
{SLAST} = SysOp's Last Name
{PROG} = The Program Name and Version Number
{ADDR} = The Port Address Stored In The .CTL File
{IRQ} = The Port IRQ Stored In The .CTL File
{SYSSEC} = SysOp Security Stored In The .CTL File
{SERIAL} = The Serial Number Stored In The .CTL File
{INSERT1}
Through
{INSERT5} = These are system variables that change from
time to time through out the program. Check
your screen files to see what their purpose
is at the time.
These variables can also be used in text files and screen files used by
your program. You will also want to look at your ANSI and RIP files with
a text editor to make sure that any Global System Variables you have used
have not been split as this will cause them to display incorrectly.
There is a neat little feature incorporated in the variables called Padding
that is used to allign text on your screen, or to ensure that variables will
only take up X amount of characters on the screen. Any underscores "_" in a
variable are translated into spaces at run time and can be used on either
side of the variable. The way to look at it is a "Pad Left" and "Pad Right"
sort of feature.
Let's try an experiment with the {USER} variable, we'll just use some
short strings of text to demonstrate the usage of variables and padding.
Let's say that the user's real name is "Jimi Hendrix". (Just because...)
Actual Text: Hello {USER}, how are you today?
Translates To: Hello Jimi Hendrix, how are you today?
Actual Text: Hello {USER________________________}, how are you today?
Translates To: Hello Jimi Hendrix , how are you today?
Actual Text: Hello {________________________USER}, how are you today?
Translates To: Hello Jimi Hendrix, how are you today?
Now, granted that these aren't really practical examples, but it shows you
how padded and non-padded variables work. Padding would be especially handy
if you were creating something like a user statistics screen. You could put
the padded variables on an ANSI background, and since there is padding in
there, the screen will always be displayed in a uniformed fashion. As you
can see in the above example, the variable {USER} is padded so there is a
total of 30 spaces on the screen. If you were to chop it down to 20, even
if the user's name was longer than 20 characters, only 20 characters will
be displayed on the screen at once.
If you have ever noticed with other programs that use variables of any kind,
to make sure that your screens always display perfectly alligned is to use
ANSI animation to go to a specific X/Y coordinate and then plot the variable
on whatever backdrop you are using. Guess what?....ASCII callers are out of
luck in this case because there is no cursor control in ACSII/TTY emulation.
Inline Color Tokens:
--------------------
As with Global System Variables, inline color tokens are used for coloring
text files and MAX screen text. Only colors 0 though 15 have any effect on
MAX screens, because colors above 15 have a blinking attribute and there
is no such thing as a blinking attribute in SVGA. If you send a color above
15 to MAXterm, it will simply be subtracted by 16 to return it to its non-
blinking counterpart.
An inline color token would look like: {14}, {1}, {31}. All colors used by
the tokens correspond to the standard ANSI color values. To color a line of
text in a message bright yellow, simply enter a {14} before the text to be
displayed. For more examples, take a look at your P#*.ANS prompt files.
Keep in mind that there is no such thing as padding in inline color tokens.
───────────────────────────────────────────────────────────────────────────────
TROUBLESHOOTING:
----------------
1. This door DOES NOT REQUIRE a fossil driver to run correctly.
2. If you are running a high speed modem (9600 baud or above), then I
suggest you run your BBS/Mailer/Doors at a locked baud rate. On high
speed error correcting modems, locking the baud rate will have a
noticable increase on the speed of text that is sent. It's beyond
the scope of this document to discuss configuring your BBS and
mailer for a locked baud rate, you may wish to consult your BBS docs
for information on that. Here are a couple things to keep in mind
when setting up door with a locked baud rate:
a. If you are using a fossil, then make sure to tell the fossil
that the port is locked. For BNU, to lock com1: at 38,400, you
would use something like "L0=38400,8N1" on BNU's command line.
b. If you lock the baud for one program, it must be locked for
everything. You can't lock the baud for just this door, but
not your BBS/Mailer.
3. If you have any incorrect settings in your NODE###.CTL file(s), you
could experience some of these situations. If you don't understand
what a certain setting in the CTL file does, it is probably best to
leave it alone, or call a computer professional and ask them for a
definition or a place to get a reference book.
a. If you have the program set to use a fossil driver or DigiBoard
and neither is present, the program will not be able to send any
resources to the remote.
b. As in the above, if any of these settings are incorrect, you and
your users will see nothing but random garbage on the screen.
c. Mismatched buffer settings, locked port speeds, port addresses,
IRQ settings, or comport selections will lock up the program on
every attempt to run it. Be sure these settings are correct.
4. What follows is some information on possible strange situations
that may occur on some systems:
a. Low speed users can use the door, but high speed users get garbage.
- If you are the DORINFOx.DEF drop file, then there is a chance
your BBS is writing the locked port speed to the drop file
rather than the actual caller baud rate. You should either
change to the DOOR.SYS drop file, or use the /S parameter to
pass the actual baud rate to the door.
Several converter programs are readily available on most
BBS systems. CallDoor is a good one if you can find it.
b. The door hangs up when a user enters the door.
- Sounds like the door is getting the wrong baud rate somehow.
Try switching over to the DOOR.SYS drop file method if possible.
- This can also be cause by using a fossil driver and locking the
comport at a rate higher than 38400. If this is the case, then
reduce your locked port speed and try again.
c. Text and screens are getting cut off.
- If you are running with a locked baud, then this could be caused
by some sort of FLOW CONTROL problem. Make sure your fossil is
loaded correctly and not locked faster than 38400 baud.
- If you're using something other than the DOOR.SYS drop file,
then I always suggest trying to use DOOR.SYS if possible. It is
the most reliable method and has had the most testing. If that
is not possible try DORINFOx.DEF as an alternative.
d. The door locks up the BBS on every node.
- This can happen with fossil driver or the internal communications
routines because it uses the default comport of 1 when NONE or
COM0: is found in the drop file.
e. ANSI is reflected correctly on the local screen but the user is
getting garbage when using DORINFOx.DEF.
- Assuming the user has ANSI installed then most likely the problem
is at your end. First make sure the dropfile is passing the actual
baud rate INSTEAD of the locked port speed. If it is not passing
correct baud rate then you may need to use DOOR.SYS instead.
f. When a user enters the door or when you run it locally, the screen
appears to cycle (flipping) over and over until the program shuts
down with a "Runtime Error 202".
- This is caused by people running hacked versions of their fossil
driver. Even though most of these hacks are nothing more than a
copy with a new version number, once it's tampered with, it's a
defective copy. Programs to avoid are BNU 2.xx and X00 2.xx. If
at all possible, get your fossil drivers author direct!
───────────────────────────────────────────────────────────────────────────────
┌───────────────────────────────────────────────────────────────────┐
│ │
│ ┌── ┌────── ┌────── ┌────── ┌────── ┌──────── │
│ ┌── ┌── ┌── ┌── ┌── ┌── ┌── ┌── │
│ ┌── ┌──────── ┌──── ┌────── ┌── ┌── ┌──── ┌── │
│ ┌── ┌── ┌── ┌── ┌── ┌── ┌── ┌── │
│ ┌────── ┌── ┌── ┌────── ┌────── ┌── ┌── │
│ │
└───────────────────────────────────────────────────────────────────┘
Not just software....It's a computer enhancement!
┌───────────────────────────────────────────────────────────────────┐
│ Contact: 1:14/703@FidoNet Or: USA MAX Graphics HQ-BBS │
│ 411:1500/0@ivNET (308)762-2239 │
│ 121:101/2@AllianceNet FAX or Data Calls │
│ maxgfx@juno.com ANSI/ASCII/MAX (No RIP) │
└───────────────────────────────────────────────────────────────────┘
───────────────────────────────────────────────────────────────────────────────
╔═══════════════════════════════════════════════════════════════════════════╗
║ You may want to freq or download the file MAXTIPS.DOC from my BBS to help ║
║ you understand the ins and outs of MAX Graphics more clearly. There isn't ║
║ anything complicated about adding MAX Graphics to your BBS or doors, but ║
║ I figure any extra help and information is better than none at all. True? ║
╚═══════════════════════════════════════════════════════════════════════════╝